1. Field of the Invention
This invention relates to the field of security in a computer network. More particularly, the present invention relates to the field of packet security in a wide area network (WAN). An example of a byte code verifier system that can be used in connection with the present invention is disclosed in the following copending patent application, which is incorporated herein by reference: xe2x80x9cB YTECODE PROGRAM INTERPRETER APPARATUS AND METHOD WITH PREVERIFICATION OF DATA TYPE RESTRICTIONS AND OBJECT INITIALIZATIONxe2x80x9d, Ser. No. 08/575,291, by Frank Yellin and James Gosling, filed on the same day as the present application.
2. Description of the Related Art
FIG. 1A illustrates a typical computing environment wherein clusters of secured computers 110a, 110b, . . . 100z, 120a, 120b, . . . 120z, . . . 160a, 160b, . . . 160z are coupled to each other to form local area networks (LANs) 110, 120, . . . 160, respectively. Exemplary technologies employed for interconnecting LANs include Ethernet and Token-ring. In turn, LANs 110, 120, . . . 160 can be coupled to each other via network nodes 115, 125, . . . , 165 to form a secured wide area network (SWAN) 100a. Typical SWAN links include dedicated leased lines and satellite links which are less vulnerable to attack than public networks in general.
In most commercial computing implementations, security is maintained by identifying internal computers whose use can be closely monitored, e.g., secured computers 110a, 110b, . . . 110z, 120a, 120b, . . . 120z, . . . 160a, 160b, . . . 160z, and also by enforcing a strict policy of not allowing any new executable programs to be executed in any one of the secured computers until these new programs have been verified as virus-free. Viruses can cause a variety of problems such as damage to hardware, software, and/or data, release information to unauthorized personnel, and/or cause a host computer to become unusable through resource depletion.
Unfortunately, most commercial networks have a need to be connected to external unsecured computers, such as the computers of telecommuting-employees and customers. For example, SWAN 100a may be coupled to external unsecured computers 190a, 190b, . . . 190z via an externally-accessible node 185a and a public switch 180.
As this need to connect SWAN 100a to an increasing number of unsecured computers 190a, 190b, 190z via public switch 180 grows, the problem of guarding the secured computers of SWAN 100a against unauthorized data access and/or data corruption becomes increasing difficult. This problem is compounded by the proliferation of computers coupled to publicly and freely accessible WANs such as the Internet. Hence, externally accessible node 185a, the weakest point of the otherwise-secure SWAN 100a, is increasingly vulnerable to hackers.
Several techniques have been developed to minimize the vulnerability of node 185a to any uninvited intrusion. For example as discussed above, whenever possible, dedicated trunk lines of switch 180 are used to connect node 185a to unsecured computers 190a, 190b, . . . 190z. A less costly but less secure alternative is the enforcement of a dialback protocol over a public network, in which an unsecured computer, e.g., computer 190a, dials up node 185a, and then identifies the remote user""s identity and location before hanging up. Subsequently, node 185a dials back computer 190a at its pre-authorized location using a pre-authorized telephone number to ensure that the remote user is indeed located at the preauthorized location.
Additional security at the packet level can also be provided at node 185a, wherein node 185a functions as a dumb xe2x80x9cfirewallxe2x80x9d which allows only pure ASCII files, e.g., textual emails, and prohibits all attachments of the emails from leaving and/or entering SWAN 100a. Alternatively, node 185a may scan all incoming packets to identify and prevent any untested executable code from entering SWAN 100a. 
Although the above-described security measures work fairly well for the exchange of data packets between SWAN 100a and unsecured computers 190a, 190b, . . . 190z, they are too cumbersome and/or inadequate for exchanging packets which include executable code. For example, in receiving an executable Internet application based on Hot Java, a programming language that supports executable applets, such a broad prohibition of executable code will effectively prevent any untested Hot Java applets from being received and subsequently executed.
Hence, there is a need for an intelligent firewall that provides real-time security testing of network packets, which may include executable code such as applets, and determines the risk level, i.e, trust worthiness, of each packet before permitting a lower-risk subset of the network packets to execute on anyone of the secured computers of SWAN 100a in a manner transparent to a user.
The present invention provides a method and apparatus for determining the trust worthiness of executable packets, e.g., internet applets, being transmitted within a computer network. The computer network includes both secured computers and unsecured computers, which are associated with secured nodes and unsecured nodes, respectively. Each executable packet has a source address and a destination address.
In one embodiment, an intelligent firewall determines within a first degree of certainty whether the source address of an executable packet arriving at one of the secured computers is associated with anyone of the secured nodes, and also determines within a second degree of certainty whether the destination address of the executable packet is associated with anyone of the secured nodes.
If the firewall determines within the first degree of certainty that the source address is associated with anyone of the secured nodes, and further determines within the second degree of certainty or is uncertain whether the destination address is associated with anyone of the secured nodes, then the firewall permits the executable packet to proceed to the secured computer.
Alternatively, if the firewall determines within the first degree of certainty or is uncertain whether the source address is associated with anyone of the secured nodes, and further determines within the second degree of certainty that the destination address is not associated with anyone of the secured nodes, then the firewall also permits the executable packet to proceed to the secured computer.
In another embodiment, the intelligent firewall determines within the first degree of certainty whether the source address of an executable packet arriving at one of the secured computers is associated with anyone of the secured nodes, or determines within the second degree of certainty whether the destination address of the executable packet is associated with anyone of the secured nodes.
If the firewall determines within the first degree of certainty that the source address is associated with anyone of the secured nodes, then the firewall permits the executable packet to proceed to the secured computer. Alternatively, the firewall determines within the second degree of certainty whether the destination address of the executable packet is associated with anyone of the secured nodes, then the firewall also permits the executable packet to proceed to the secured computer.
In the above-described embodiments, if none of the above-described trust-worthiness conditions are satisfied, then the firewall rejects the executable packet, thereby minimizing the risk of damage to the secured computer.